Efficient handling of mostly read data in a computer server

ABSTRACT

An apparatus and method is described for improving access to mostly read data on network servers. The preferred embodiments more efficiently utilize replicated data servers to minimize server response time for improved performance of data access to network servers by workload managing client requests across the primary server and all replicated servers when it is possible to do so. In preferred embodiments, a load balancer supplies the most current data for mostly read data transactions while maximizing server usage by workload managing client requests across the primary server and all replicated servers. Client requests are managed by a load balancer in the workload manager. Client requests are sent by the load balancer to replicated servers when a routing table (stale data marker list) indicates that the data is in a safe period. Clients are directed exclusively to the primary server only during data update times.

CROSS-REFERENCE TO PARENT APPLICATION

This patent application is a continuation of “U.S. Ser. No. 11/422,687filed on Jun. 7, 2006, which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Technical Field

This invention generally relates to computer servers and morespecifically relates to an apparatus and method for efficiently handlingmostly read in a computer server environment that maintains dataintegrity while maximizing server utilization through workloadmanagement.

2. Background Art

Essential to computer performance is the timely availability of data.Computer systems often employ servers that are connected over a networkto provide data files and software application files to a number ofclient machines. The same data is replicated onto multiple servers toachieve high availability, scalability of the systems and higherperformance. High availability means availability despite plannedoutages for upgrades or unplanned outages caused by hardware or softwarefailures through fragmentation and replication of data across multipleservers.

In HA systems and in other computer systems, duplicate data is stored onmultiple servers to timely respond to request from many differentlyclients. Typically, a workload manager with a dispatcher is used tomanage the workload of the client requests to ensure efficientutilization of the servers to maximize the performance of the servers.Data stored on a server can generally be classified as one of fourtypes: 1) read/write data, 2) mostly read data with a specific updateperiod, 3) mostly read data with uncertain update times, and 4) readonly data. If data stored on the servers is read only data, thenworkload management can simply direct client requests to access anyserver. FIG. 2 shows how a client 210 may access the data on any server212 for read only transactions 214. Since the read only data is currentin all the servers, the request for read-only data can be routed to theprimary server 216 and to the replicated servers 218, 220.

However, if the data stored on the server is type 1, 2 or 3, then onlythe data on the primary server 216 is always valid and current. Withthese other types of data, such as read/write transactional data andmostly read data, the data stored in different servers may be differentduring data updates. Therefore, for these types of data transactions222, all clients data requests are directed to the primary server onlyand all replicated servers are not used for these operations. FIG. 3illustrates the work load manager (not shown) directing data requests222 by all clients 212 to the primary server 216. Also, FIG. 3illustrates the typical situation in HA systems, where all access ismade to the primary server, and the other servers are replicated on adelayed basis. These replicated servers are wasted in terms of clientaccess usage. The replicated servers are used only when primary serversfail, but since it is very rare for the primary servers to fail, theservers are not well utilized.

In the prior art, when data stored on the server is mostly read data,the primary server must be used to guarantee the data is current (notstale). Since up to 80% of a typical database contains mostly read datawith very few updates and a large number of reads, large amounts ofserver resources are wasted, and scalability and performance are greatlydiminished. Since mostly read data is updated infrequently, thereplicated servers could be better utilized at times when they arecurrent and the data is not stale. Without a way to more efficientlyutilize servers for mostly read data, the computer industry willcontinue to suffer from slower response and less efficient utilizationof network servers.

BRIEF SUMMARY OF THE INVENTION

According to the preferred embodiments, an apparatus and method isdescribed for efficient utilization of replicated data servers tominimize server response time and to enable larger scalability tosupport many concurrent clients. In preferred embodiments, a loadbalancer supplies the most current data for mostly read datatransactions while maximizing server usage by workload managing clientrequests across the primary server and all replicated servers. Clientrequests are managed by a load balancer in the workload manager. Clientrequests are sent by the load balancer to replicated servers when arouting table (stale data marker list) indicates that the data is in asafe period. Clients are directed exclusively to the primary server onlyduring data update times.

While the preferred embodiments described herein are directed to theWebSphere server environment, the claimed embodiments herein expresslyinclude other web server environments with their associatedarchitectures and files.

The foregoing and other features and advantages of the invention will beapparent from the following more particular description of preferredembodiments of the invention, as illustrated in the accompanyingdrawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

The preferred embodiments of the present invention will hereinafter bedescribed in conjunction with the appended drawings, where likedesignations denote like elements, and:

FIG. 1 is a block diagram of an apparatus in accordance with a preferredembodiment of the present invention;

FIG. 2 is a block diagram that represents read only transactions byclients to network servers according to the prior art;

FIG. 3 is a block diagram that represents mostly read and read/writetransactions by a client to network servers according to the prior art;

FIG. 4 is a block diagram that represents mostly read transactions byclients to network servers according to preferred embodiments;

FIG. 5 a is a block diagram that represents read only transactions bymultiple clients through a single client server to network serversaccording to preferred embodiments;

FIG. 5 b is another a block diagram that represents read onlytransactions by clients with different workload managers to accessnetwork servers according to preferred embodiments;

FIG. 6 is a block diagram that represents the contents of a stale datamarker list according to preferred embodiments;

FIG. 7 is flow diagram that represents a method of request flow handlingaccording to preferred embodiments;

FIG. 8 is flow diagram that represents a method of creating and updatinga stale data marker list according to preferred embodiments;

FIG. 9 is flow diagram that represents a method for comparing versionsof a routing table and stale data marker list between the client sideand server side according to preferred embodiments;

FIG. 10 is flow diagram that represents a method of forwarding requestsfor newly changed data according to preferred embodiments; and

FIG. 11 is flow diagram that represents a method of cleaning stale datamarker list entries after the replication time according to preferredembodiments.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to application servers and in particularthe WebSphere application server is used for the illustrated examples.For those who are not familiar with WebSphere and application servers,the brief overview below provides background information that will helpthe reader to understand the present invention.

1. Overview WebSphere Application Server in the WebSphere Environment

WebSphere is the IBM brand of software products that are designed towork together to deliver dynamic e-business solutions for connectingpeople, systems, and applications with internal and external resources.The WebSphere environment of software products includes an applicationserver. WebSphere is based on infrastructure software (middleware)designed for dynamic e-business. It delivers a secure, and reliablesoftware portfolio. The technology that powers WebSphere products isJava™. Over the past several years, many software vendors havecollaborated on a set of server-side application programmingtechnologies that help build Web accessible, distributed,platform-neutral applications. These technologies are collectivelybranded as the Java 2 Platform, Enterprise Edition (J2EE). Thiscontrasts with the Java 2 Standard Edition (J2SE) platform, with whichmost clients are familiar. J2SE supports the development of client-sideapplications with rich graphical user interfaces (GUIs). The J2EEplatform is built on top of the J2SE platform. J2EE consists ofapplication technologies for defining business logic and accessingenterprise resources such as databases, Enterprise Resource Planning(ERP) systems, messaging systems, e-mail servers, and so forth.Enterprise JavaBeans (EJB) technology is the server-side componentarchitecture for Java Platform, Enterprise Edition (Java EE). EJBtechnology enables rapid and simplified development of distributed,transactional, secure and portable applications based on Javatechnology.

2. Detailed Description

According to a preferred embodiment of the present invention, anapparatus and method is described for efficient utilization ofreplicated data servers to minimize server response time and to enablelarger scalability to support many concurrent clients. The preferredembodiments described herein make it possible to efficiently work loadmanage data requests across all servers (both primary and replicas)while ensuring data integrity and data freshness.

Referring to FIG. 1, a computer system 100 is one suitableimplementation of an apparatus in accordance with the preferredembodiments of the invention. Computer system 100 is an IBM eServeriSeries computer system. However, those skilled in the art willappreciate that the mechanisms and apparatus of the present inventionapply equally to any computer system, regardless of whether the computersystem is a complicated multi-user computing apparatus, a single userworkstation, or an embedded control system. As shown in FIG. 1, computersystem 100 comprises a processor 110, a main memory 120, a mass storageinterface 130, a display interface 140, and a network interface 150.These system components are interconnected through the use of a systembus 160. Mass storage interface 130 is used to connect mass storagedevices, such as a direct access storage device 155, to computer system100. One specific type of direct access storage device 155 is a readableand writable CD RW drive, which may store data to and read data from aCD RW 195.

Main memory 120 in accordance with the preferred embodiments containsdata 121, an operating system 122, a client server 123, and a dataserver 127. Data 121 represents any data that serves as input to oroutput from any program in computer system 100. Operating system 122 isa multitasking operating system known in the industry as i5/OS; however,those skilled in the art will appreciate that the spirit and scope ofthe present invention is not limited to any one operating system. Clientserver 123 and data server 127 are software systems similar in manyrespects to those known in the art, but with additional features thatare not known in the art. The client server 123 includes a workloadmanager 124 that manages client requests to data as described below. Inpreferred embodiments, the data server 123 includes a stale data markerlist 125 that is used in conjunction with a routing table 126. The dataserver 127 also includes a stale data marker list 128 that is used inconjunction with a routing table 129. These elements of the preferredembodiments are described further below.

Computer system 100 utilizes well known virtual addressing mechanismsthat allow the programs of computer system 100 to behave as if they onlyhave access to a large, single storage entity instead of access tomultiple, smaller storage entities such as main memory 120 and DASDdevice 155. Therefore, while data 121, operating system 122, clientserver 123, and data server 127 are shown to reside in main memory 120,those skilled in the art will recognize that these items are notnecessarily all completely contained in main memory 120 at the sametime. In fact, the client server 123 and the data server 127 are mostlikely to reside in different computer systems as described below. Itshould also be noted that the term “memory” is used herein togenerically refer to the entire virtual memory of computer system 100,and may include the virtual memory of other computer systems coupled tocomputer system 100.

Processor 110 may be constructed from one or more microprocessors and/orintegrated circuits. Processor 110 executes program instructions storedin main memory 120. Main memory 120 stores programs and data thatprocessor 110 may access. When computer system 100 starts up, processor110 initially executes the program instructions that make up operatingsystem 122. Operating system 122 is a sophisticated program that managesthe resources of computer system 100. Some of these resources areprocessor 110, main memory 120, mass storage interface 130, displayinterface 140, network interface 150, and system bus 160.

Although computer system 100 is shown to contain only a single processorand a single system bus, those skilled in the art will appreciate thatthe present invention may be practiced using a computer system that hasmultiple processors and/or multiple buses. In addition, the interfacesthat are used in the preferred embodiment each include separate, fullyprogrammed microprocessors that are used to off-load compute-intensiveprocessing from processor 110. However, those skilled in the art willappreciate that the present invention applies equally to computersystems that simply use I/O adapters to perform similar functions.

Display interface 140 is used to directly connect one or more displays165 to computer system 100. These displays 165, which may benon-intelligent (i.e., dumb) terminals or fully programmableworkstations, are used to allow system administrators and users tocommunicate with computer system 100. Note, however, that while displayinterface 140 is provided to support communication with one or moredisplays 165, computer system 100 does not necessarily require a display165, because all needed interaction with users and other processes mayoccur via network interface 150.

Network interface 150 is used to connect other computer systems and/orworkstations (e.g., 175 in FIG. 1) to computer system 100 across anetwork 170. The present invention applies equally no matter howcomputer system 100 may be connected to other computer systems and/orworkstations, regardless of whether the network connection 170 is madeusing present-day analog and/or digital techniques or via somenetworking mechanism of the future. In addition, many different networkprotocols can be used to implement a network. These protocols arespecialized computer programs that allow computers to communicate acrossnetwork 170. TCP/IP (Transmission Control Protocol/Internet Protocol) isan example of a suitable network protocol.

At this point, it is important to note that while the present inventionhas been and will continue to be described in the context of a fullyfunctional computer system, those skilled in the art will appreciatethat the present invention is capable of being distributed as a programproduct in a variety of forms, and that the present invention appliesequally regardless of the particular type of computer-readable mediaused to actually carry out the distribution. Examples of suitablecomputer-readable media include recordable type media such as floppydisks and CD RW (e.g., 195 of FIG. 1). Note that the preferredcomputer-readable media is tangible.

It is also important to point out that the presence of network interface150 within computer system 100 means that computer system 100 may engagein cooperative processing with one or more other computer systems orworkstations on network 170. Of course, this in turn means that theprograms and data shown in main memory 120 need not necessarily allreside on computer system 100. For example, one or more portions shownin main memory 120 may reside on another system and engage incooperative processing with one or more objects or programs that resideon computer system 100. This cooperative processing could beaccomplished through use of one of the well known client-servermechanisms such as remote procedure call (RPC).

According to preferred embodiments, an apparatus and method is describedfor efficient utilization of replicated data servers to minimize serverresponse time. The preferred embodiments described herein make itpossible to efficiently work load manage data requests across bothprimary and replicated servers while ensuring data integrity and datafreshness. FIG. 4 illustrates a computer network system 400 that directsclient requests according a preferred embodiment for more efficientutilization of replicated data servers. The client computers 410, 412are able to access the most current data for mostly read datatransactions while maximizing server usage by workload managing clientrequests across the primary server and all replicated servers bymonitoring when data is fresh or stale on the servers. Requested data issupplied exclusively from the primary server 416 for data requests(mostly read transactions 414) when data on the replicated servers isstale. Mostly read type data on the replicated servers is stale duringupdate and replication times. Mostly read transactions 414 are directedonly to the primary server when the data on the replicated servers isstale as shown by the solid lines in FIG. 4. At other times, whenupdates are not occurring and thus the data that is replicated acrossthe other servers is fresh or current data, the data requests areworkload managed across all the servers 416, 418, and 420 as shown bythe dashed lines from the clients 410, 412.

In the preferred embodiments the servers 416, 418 and 420 each have astale data marker list 422, 423, 424 that corresponds to the stale datamarker list shown in the data server 124 of FIG. 1. The stale datamarker lists 422, 423, 424 indicate what data is stale or not current.The system is then able to determine when to exclusively access theprimary server 416 or when fresh data can be workload managed across allthe servers as described above. The stale data markers in list 422, 423,424 are similar to dirty bits used in a computer memory cache. The staledata marker list is used in conjunction with the routing table todetermine where to access data. The stale data marker list can be viewedas an extension of the routing table. The routing table contains a listof all end points that have data, including the primary and serverreplicas. The routing table is used by the workload manager inconjunction with the stale data list to determine where to access data.When a request for data is processed by the workload manager, the staledata marker list is checked to see if the requested data has an entry inthe stale data list. Any data that is stale or in the process of beingupdated in the replicated servers is marked in the stale data markerlist 422 so that any clients that request this data are routed to theprimary server only to ensure data integrity. In the preferredembodiments, the stale data marker list has a key for each entry that isassociated with the stale data as described further below.

FIG. 5 a illustrates a system topography for implementing thefunctionality described with FIG. 4 to maximize the efficiency ofreplicated servers according to preferred embodiments. Client 1 410 andClient 2 412 access data on the primary server (data server1) 127 a andthe replicated servers 127 b, 127 c as described above. Data access byclient 1 and client 2 is facilitated by a client server 123. The clientserver 123 includes a workload manager 124. The workload manager 124 andthe client server 123 operate similar to prior art workload managementtechniques that workload manage read only data requests to replicatedservers. In contrast to the prior art, the workload manager 124 of thepreferred embodiments uses the stale data marker lists 125, 128 a, 128b, 128 c to workload manage mostly read data requests to the replicatedservers as described herein. The stale data marker lists 128 a, 128 b,and 128 c are local replicas of the stale data marker list 125. Thestale data marker lists 128 a, 128 b, and 128 c are updated and includea timestamp as described further below.

FIG. 5 b illustrates another topography for implementing an apparatusfor maximizing the efficiency of replicated servers to access mostlyread data according to preferred embodiments. The system in FIG. 5 boperates in a similar manner as the system described above withreference to FIG. 5 a. Client 1 410 and client 2 412 access data on theprimary server (data server1) 127 a and the replicated servers 127 b,127 c as described above. In this system, the workload manager isincorporated on the client side of the system and shown included in theclients 410, 412. In preferred embodiments, the clients 410, 412 areJava virtual machines (JVMs). Client 1 410 includes a workload manager124 a with a stale data list 125 a, and Client 2 412 includes a workloadmanager 124 b with a stale data list 125 b. The stale data marker lists124 a, 124 b are updated separately by the corresponding workloadmanager as described below with reference to FIG. 11. In this manner,many clients from different machines or different JVMs can be supportedas described herein to workload managed mostly read data on replicatedservers.

The two topologies of FIGS. 5 a and 5 b illustrate how the workloadmanager is located one level ahead of target server for differenttopologies. In a preferred embodiment of a multiple tier architecture,the workload manager is in the WebSphere edge server to work load managehttp server requests. In another embodiment, the workload manager is inhttp servers to work load manage servlet requests into WebSphereapplication server Web Containers. In another embodiment, the workloadmanager is in a WebSphere application server servlets containers toworkload manage requests to WebSphere application server EJB containers.In another embodiment, the workload manager can be in EJB containers toworkload manage requests to different database servers. One server canact as client of another server. In the client mode shown in FIG. 5 b,for example, java clients, or client clients download the routing table(stale data marker list) on the fly to direct requests to differentservers.

FIG. 6 illustrates additional detail of the stale data marker list 422according to preferred embodiments. The stale data marker list 422includes a list of stale data markers 612, where each stale data markeris an entry in the list. In preferred embodiments, each stale datamarker 612 has a key 614 and one or more corresponding change times 616and a replication time 618 or cool down period. The key 614 ispreferably an index key for a data set stored on the data server thatcan be accessed by a client. The key can be any type of pointer orreference to identify data on the server. The change times 616 for eachkey 614 is the times when the data in the database corresponding to thedata key is being updated. The data is updated by the primary server inresponse to client requests (insert, update, or delete). A stale datamarker 612 is placed in the stale data marker list by a continuousrunning process of the workload manager that monitors data updates inthe system. The stale data marker is valid within the replication time618 after the change time 616. When the stale data marker is valid thestale data marker 612 is placed in the stale data marker list. The staledata marker list is cleared of non-valid stale data markers by anotherprocess described further below.

The replication time 618 in the stale data marker list 422 is acalculated amount of time required to propagate the change in data fromthe primary server to all the respective replicas of the primary server.The replication time 618 is the time to wait after the change time 616before it is statistically safe to access data corresponding to therespective key 614 on a replicated server. The replication time 618 isthe statistically calculated propagation time for 1 sigma, 2 sigma, 3sigma or for some percentage of the data to be propagated from theprimary server to the replicated servers. In preferred embodiments, thesigma level or percentage is user definable. Therefore, beginning at thechange time and before the change time plus the replication time is theunsafe period, where it is unsafe to access the corresponding data fromthe server replicas because the data may be stale. Any time after thechange time plus the propagation time and before the next change time isa safe period for clients to access data from the replicated servers.For mostly read data that is updated infrequently there is a largeamount of safe period. For example, if the mostly read data is updated24 times per day, and the geographical replication time take 2 minutesbetween data centers, then there is 58 minutes of safe period to accessdata from all replicated servers, and only 2 minutes of unsafe period.During the unsafe period, client requests are routed exclusively to theprimary server to ensure data integrity and currency. In this way,scalability and server utilization can be substantially increased, as inthis example by over 95%.

Referring now to FIG. 7, a method 700 is shown according to preferredembodiments herein. Method 700 illustrates a method for implementing aworkload manager to access data in a database using the keys in thestale data marker list according to preferred embodiments. The methodbegins with the workload manager receiving client requests for data(step 710). The data key for the client requested data is then extractedfrom the request (step 720). If the data is not stale since thecorresponding key is not in the stale data list (step 730=no), then theload balancer in the work load manages the data requests by routing thedata requests to all the servers (step 750) and the method is done. Ifthe data is stale (the data key is in the stale data list) (step730=yes), then the data is routed exclusively to the primary server(step 740) and the method is done.

Referring now to FIG. 8, a method 800 is shown to create and broadcastthe stale data marker list according to preferred embodiments herein. Asshown in FIG. 4, the stale data marker list in preferred embodiments ismaintained in each of the data servers to insure access is made to dataon the replicated servers when the data is valid (not stale). In thepreferred embodiments, the workload manager monitors access to data toupdate the contents of the stale data marker list, and then broadcaststhe updates to each server's copy of the stale data marker list. Themethod 800 describes this process to maintain the stale data markerlist. The workload manager monitors data access (insert, delete, update)(step 810) to the database. The propagation time is extracted fromclient accesses to the database (step 820). The propagation time is theactual amount of time used to make the updates to the replicateddatabase servers to bring the data in those servers current with thedata in the primary server. The propagation time is used to calculate areplication time to be stored in the stale data marker list (step 830).The replication time and change time are determined for the datacorresponding to a key and the stale data marker list is updated (step840). The stale data marker list is replicated to the primary andreplicated servers (step 850). The method is then done.

In preferred embodiments, the routing tables and stale data marker listsare maintained and coordinated using epochs or timestamps. The workloadmanager in the client server inserts a timestamp that reflects the stateof the routing table and stale data marker list into the data requestthat is sent to the data server. When a client receives a response, theresponse carries a similar timestamp. If this response timestamp isnewer, then the client server receives an update to the routing tableand stale data marker list. On the data server side, when a request fordata is received, the timestamp of the data request is compared to thetimestamp of the local routing table and stale data marker list. If thetimestamps do not match, the request is forwarded to a server with anewer routing table and stale data marker list, and if needed a newversion of the routing table and stale data marker list is sent to theclient server in a response to the data request. These operations aredescribed further below with reference to FIGS. 9 and 10. FIG. 9illustrates the actions on the client server side to maintain therouting tables and stale data marker lists. FIG. 10 illustratesoperations on the data server side.

Referring now to FIG. 9, a method 900 is shown to update the serverrouting table and stale data marker list according to preferredembodiments herein. The workload manager on the client server sideinserts an timestamp or epoch into the data request that is sent to thedata server (step 910). The timestamp is the last update time of thestale data marker list on the server side. After a response from thedata request is received, the workload manager compares the timestamp inthe response with its local routing table timestamp to determine if thelocal routing table and stale data marker list is current (step 930). Ifthe timestamps do not match and the local stale data marker list is notcurrent (step 930=no), then the server updates its routing table andstale data marker list with response objects containing this informationfrom the server (step 940). If the timestamps do match and the localstale data marker list is current (step 930=yes), then the method isdone.

Referring now to FIG. 10, a method 1000 is shown to process datarequests on the server according to preferred embodiments herein. Thedata server checks incoming requests with the server's local stale datamarker list to insure data integrity. This is important when there is achange in the data but the change is not detected in time by theworkload manager that dispatches this request. In this case, the serverwill detect the stale data by comparing the version of its own staledata marker list with the version inserted by client, and if they aredifferent rerouting the data request to the primary server as will bedescribed with reference to method 1000.

Method 1000 begins with the data server comparing the incoming timestampwith the local routing table timestamp to determine if the local staledata marker list is current (step 1010). If the local stale data markerlist is current (the timestamps match) (step 1020=yes), then the datarequest is processed locally (step 1030) and the method is done. If thelocal stale data marker list is not current (the timestamps do notmatch) (step 1020=no), and the server is the primary server (step1040=yes), then the data request is processed locally and a new versionof the routing table and stale data marker list is send in the responsestream to the client server (step 1050). If the timestamps do not match(step 1020=no), the server is not the primary server (step 1040=no), andthe requested data is not changed data in the routing table and thestale data marker list (step 1060=no) then the data request is processedlocally and a new version of the routing table and stale data markerlist is send in the response stream to the client server (step 1050). Ifthe timestamps do not match (step 1020=no), the server is not theprimary server (step 1040=no), and the requested data is changed data inthe routing table and the stale data marker list (step 1060=yes) thenthe data request is forwarded to the primary server (step 1070) and themethod is done. The primary server will processes the request with thissame method, which will result in a new version of the routing table andstale data marker list being sent in the response stream to the clientserver (step 1050).

Referring now to FIG. 11, a method 1100 is shown to process and updatethe stale data marker list according to preferred embodiments herein. Inpreferred embodiments, software according to this method is periodicallyrun on the primary server to keep the stale data marker list up to date.The next stale data marker in the stale data marker list is selected tobe updated (step 1110). If the elapsed time is greater than thecorresponding replication time in the stale data marker list (step1120=yes) then the stale data marker with this key is cleared from thestale data marker list (step 1130). If the elapsed time is not greaterthan the corresponding replication time in the stale data marker list(step 1120=no) then proceed to check the next data marker (step 1140).If there are more markers in the list (step 1140=yes) then jump to step1110. If there are no more markers in the list (step 1140=no) then themethod is done.

An apparatus and method has been described for improving access tomostly read data on network servers. The preferred embodiments moreefficiently utilize replicated data servers to minimize server responsetime for improved performance of data access to network servers byworkload managing client requests across the primary server and allreplicated servers when it is possible to do so.

One skilled in the art will appreciate that many variations are possiblewithin the scope of the present invention. Thus, while the invention hasbeen particularly shown and described with reference to preferredembodiments thereof, it will be understood by those skilled in the artthat these and other changes in form and details may be made thereinwithout departing from the spirit and scope of the invention.

1. A computer method for workload managing mostly read transactions, themethod comprising the steps of: (A) a client server receiving a datarequest from a client; (B) extracting a key from the data request; (C)routing the data request to a primary server if the data correspondingto the key is stale; and (D) routing the data request to a replicatedserver if the data corresponding to the key is not stale.
 2. The methodof claim 1 further comprising the steps of: (E) monitoring changes tothe data; (F) extracting historical propagation times and change times;(G) calculating the replication time from the propagation time; (H)updating a stale data marker with the replication time; and (I)replicating the stale data marker to one or more replicated dataservers.
 3. The method of claim 1 further comprising the steps of: (J)inserting a timestamp for a stale data marker in a request for data to adata server; (K) the data server comparing the timestamp with atimestamp for a local stale data marker list; and (L) forwarding therequest for data to a primary server if the timestamps do not match andprocessing the request for data at the local data server if thetimestamps match.
 4. The method of claim 1 further comprising the stepsof: (M) selecting the next stale data marker in a stale data markerlist; (N) determining if the stale data marker is still needed bycomparing the time elapsed with the replication time; and (O) clearingthe stale data marker from the stale data marker list if the elapsedtime is greater than the replication time.
 5. The method of claim 1wherein the client server is part of WebSphere.